Single Blog

Trendmicro
exposes the criminal organization TeamTNT for a second time.

The report published by the security company confirms that it has found a second version of the botnet, more powerful and refined. If an early version of the malware only affected Docker, it is now also able to affect the servers of AWS.

TeamTNT developers aren’t just interested in mining anymore, but now malicious scripts are being developed to steal data such as credentials and passwords. In addition, the new version of the botnet is able to prepare the environment to make sure that it has enough resources to undermine the security of other platforms, in fact, they hide in the system and also install backdoors in case they need to connect remotely to the infected servers.

What’s going on? TeamTNT accesses exposed Docker containers, installs cripot mining malware, and steals credentials for AWS servers in order to pivot to a company’s other IT systems to infect even more servers and deploy cryptocurrency miners. This type of attack is dangerous for companies that are exposed online and also for those that use Docker management APIs. At this point a question arises, is it really possible to suffer such an attack? How can you leave space and give free access to containers?

The answer is related to one of the following alternatives:

• Bugs in the application, or other pieces of software contained in the container;
• Docker APIs exposed to all;
• Unsecured or poorly protected Git repositories (public finite credentials, etc.);
• Any DB used by the application exposed on the internet.

In order not to fall into the error and avoid exposing yourself to risks of this type, we have drawn up a list of Best Practices to be put in place to protect customers from a possible malware attack:

• Using IAM Roles instead of using programmatic keys such as Access Key and Secret Access for authenticated calls to AWS services
• Networking organization with public/private subnets to secure “master” nodes if using EKS or not exposing EC2 in case of ECS on EC2
• Have a single point of access to the infrastructure (such as CDN) that will then be protected with Web Application Firewall (WAF) to avoid DDoS, XSS, SQL Injection attacks (level 7 protection ISO/OSI stack) and level 3-4 protection.
• Always use private repositories (Code Commit/git/ecr)
• Do not expose application credentials in repositories but with other solutions, such as S3 buckets locked by strict policies, AWS System Manager.

In addition, it should be remembered that all calls to AWS services require authentication, even via API, and that AWS does not expose anything on the internet by default.

Here are two real-world case studies on which VMEngine was able to set all security policies in the best possible way, positively affecting performance and making the IT architecture secure and scalable: